Technical Field
The present disclosure generally relates to debugging a software program. More particularly, but not exclusively, the present disclosure relates to a hardware-based debugging support unit useful for debugging the software program.
Description of the Related Art
Ever since developers have been writing software code, there has been a need to debug software. In some cases, when software does not work properly, a developer studies the software code and tries to debug the problem mentally. In many cases, particularly when the software is more than a short simple program, a mental approach to debugging software will not work.
Various tools have been created to assist developers to debug software. In some cases, the conventional debugging tools are formed entirely from software. In other cases, the conventional debugging tools are formed from a combination of hardware and software.
FIG. 1 is a conventional debugging system 10. In the system, a host computing device 12 is communicatively coupled to a target system 50 via a serial communication medium 34. The host computing device 12, which is typically a personal computer, includes a hardware module 14 and a memory module 16. The hardware module 14 includes a processor 18 along with a support logic module 20. The memory module 116 typically includes operating system software 22, application software 24, and a debug software program 26.
The host computing device 12 is generally under the control of a software practitioner, such as a developer. The developer receives information from the host computing device 12 via a display 28, and the developer provides information to the host computing device 12 via a keyboard 30 and a mouse 32. Under the direction of the software practitioner, the processor 18 executes software instructions stored in the memory module 16.
The support logic module 20 of the host computing device 12 includes circuitry such as universal asynchronous receiver/transmitter (UART) controllers, memory controllers, clocks, graphics controllers, and the like. At the direction of the software practitioner, the debug software program 26 communicates with the target system to send control information and receive data or status information. In the conventional debugging system 10 of FIG. 1, control information and data is passed through a UART of the support logic module 20 to the target system 50 over a serial communication medium 34 (i.e., a serial data cable). In addition, data and status information is passed from the target system 50 over the serial communication medium 34 to the host computing device 12.
The target system 50 of FIG. 1 includes a processor 52, a support logic module 54, a memory module 56, and a conventional debugging support unit (DSU) 58. Support logic module 54 of the target system 50 is along the lines of the support logic module 20 of the host computing device 12. In addition to communication controllers, memory controllers, clocks, graphics controllers, and the like, the support logic module 54 may also include other circuits and structures to support the functionality of the target system 50.
Resident in the memory module 56 of the target system 50 is a program 60. The program 60 includes software instructions executable by the processor 52 to carry out the functions of the target system 50. A stub 62 is optionally located within the set of software instructions of the program 60. In some cases, one or more stubs 62, which are described in more detail below, are placed in the program 60.
The DSU 58 includes an optional processor 64, optional DSU software 66, and an optional logic module 68. The DSU 58 directs debugging operations on-board the target system 50. In cases where the DSU 58 includes the optional processor 64, the DSU 58 will also include the optional DSU software 66, which includes software instructions executable by the optional processor 64. The optional logic module 68 of the DSU 58 may include registers, comparators, clocks, input/output circuits, and the like, to facilitate debugging operations. In a conventional implementation of target system 50, operations of the DSU 58 are directed by the software practitioner. The software practitioner uses the host computing device 12 to enter debugging commands, which are interpreted by the debug software program 26 and communicated via the serial communication medium 34 to the target system 50.
A conventional debugging method used by the software practitioner is referred to as the “stub” method. The stub method is implemented substantially in software. In the stub method, a software practitioner identifies an area in the program 60 where a suspected bug may be found. Then, in this area, a selected instruction in the program 60 is replaced with an illegal instruction. The illegal instruction is one that is not understood by the processor 52, so that when the processor 52 tries to execute the illegal instruction, which is the stub 62, the processor 52 will instead assert an illegal-instruction trap. Rather than traditional illegal-instruction trap handler, the incidence of the illegal-instruction trap causes the DSU 58 to perform debugging operations. That is, the DSU 58 allows the software practitioner to “take over” control of the target system 50 at the point in the program 60 where the software practitioner believes there is a bug.
For example, if the target system 50 is failing to illuminate a certain light emitting diode (LED) when a particular condition is encountered, the software practitioner may identify the portion of program 60 where software instructions interrogate the particular condition. The address of one of those software instructions is selected by the software practitioner, and the original software instruction is replaced with the illegal software instruction. The software practitioner performs this replacement by entering commands at the host computing device 12, which direct the DSU 58 to perform the replacement.
After the stub 62 is placed in the memory address space of the program 60, the processor 52 is permitted to execute the instructions of program 60 as normal. When the illegal instruction (i.e., the stub 62) is encountered, the processor 52 will suspend its normal instruction flow, save a current state of the processor, and load a program counter (PC) register with the address of a predetermined trap handler. The predetermined trap handler includes debugging software instructions. For example, the first instructions in the predetermined trap handler may save the contents of one or more registers of the processor 52 in a temporary memory space, save the contents of other portions of memory in the temporary memory space, or take other actions to capture the state of the target system 50 at the moment the illegal instruction (i.e., the stub) was encountered. Within the predetermined trap handler, the software practitioner can also interactively read registers of processor 52, read and write data or software instructions in memory module 56, or perform other actions to try and determine where the bug in the program 60 exists.
When the software practitioner has determined that sufficient debugging has been performed, the software practitioner will direct the DSU 58 to replace the stub 62 with the original software instruction of program 60 that was present before the stub 62 was loaded, and the registers and memory areas previously saved in the temporary storage space will be restored. Next, the software practitioner will direct the processor 52 to return from the predetermined trap handler. The processor 52 will restore the original state of the processor, and reload the PC register with the address of the now replaced software instruction. In this way, execution of the program 60 will resume where it was previously interrupted and with a context and state as it existed prior to the trap.
Returning to the previous example of failing to illuminate an LED, the software practitioner will force the DSU 58 to place one or more stubs 62 in strategic areas of program 60. As the processor 52 executes the software instructions of program 60 and encounters each stub 62, the software practitioner has an opportunity to identify why the expected particular condition is not realized, why the expected particular condition is not properly interrogated, why the LED is not illuminating, or some other bug.
In the stub method, a software practitioner strategically places one or more stubs 62 in areas of program 60 where debugging is desired. At each point where a stub 62 is encountered, an illegal-instruction trap is triggered, and the software practitioner has an opportunity to interrogate or otherwise control the target system 50. As bugs are discovered, the software instructions of program 60 can be updated or otherwise rewritten to remove the bugs.
All of the subject matter discussed in the Background section is not necessarily prior art and should not be assumed to be prior art merely as a result of its discussion in the Background section. Along these lines, any recognition of problems in the prior art discussed in the Background section or associated with such subject matter should not be treated as prior art unless expressly stated to be prior art. Instead, the discussion of any subject matter in the Background section should be treated as part of the inventor's approach to the particular problem, which in and of itself may also be inventive.